If a "PEM-like" OpenSSH format private key:

1. has no comment;
2. is of a length such that there is no padding bytes at the end of the "Unencrypted list of N private keys"; ***and***
3. is of a length such that the base64-encoded form of the key does not require any `=` bytes for padding;

then `ssh_key::private::PrivateKey::from_openssh` fails to successfully parse the key.

The root cause is `base64ct` (prior to RustCrypto/formats#1387) incorrectly rejecting zero-length reads when the base64-encoded buffer was empty.
This wouldn't happen if:

1. the key had a comment, because that wouldn't be a zero-length read;
2. there were padding bytes in the "Unencrypted list of N private keys", because those padding bytes would still be in the buffer, so the buffer wasn't empty; *or*
3. there were base64 `=` padding characters, because those would cause the decoder to believe a read would succeed (even though it wouldn't if the read was longer than zero bytes).

Debugging this was... an amusement.

The most reliable way to demonstrate this is with an ECDSA P-256 key without a comment (easily generated with `ssh-keygen -t ecdsa -b 256 -C '' -N '' -f <file>`),
because they *usually* (but not *always*) are of an appropriate length to trigger the bug.
Amusingly (cough), the existing ECDSA P-256 key in `ssh-key/tests/examples/id_ecdsa_p256` is one of the outliers, as its `d` is 33 bytes, rather than 32, which means that key (when stripped of its comment) *doesn't* trigger the bug.

If a "PEM-like" OpenSSH format private key:

1. has no comment;
2. is of a length such that there is no padding bytes at the end of the "Unencrypted list of N private keys"; ***and***
3. is of a length such that the base64-encoded form of the key does not require any `=` bytes for padding;

then `ssh_key::private::PrivateKey::from_openssh` fails to successfully parse the key.

The root cause is `base64ct` (prior to RustCrypto/formats#1387) incorrectly rejecting zero-length reads when the base64-encoded buffer was empty.
This wouldn't happen if:

1. the key had a comment, because that wouldn't be a zero-length read;
2. there were padding bytes in the "Unencrypted list of N private keys", because those padding bytes would still be in the buffer, so the buffer wasn't empty; *or*
3. there were base64 `=` padding characters, because those would cause the decoder to believe a read would succeed (even though it wouldn't if the read was longer than zero bytes).

Debugging this was... an amusement.

The most reliable way to demonstrate this is with an ECDSA P-256 key without a comment (easily generated with `ssh-keygen -t ecdsa -b 256 -C '' -N '' -f <file>`),
because they *usually* (but not *always*) are of an appropriate length to trigger the bug.
Amusingly (cough), the existing ECDSA P-256 key in `ssh-key/tests/examples/id_ecdsa_p256` is one of the outliers, as its `d` is 33 bytes, rather than 32, which means that key (when stripped of its comment) *doesn't* trigger the bug.

Adjust to the changes to `base64ct` that reject zero-length decode() calls as invalid.

The underlying trigger for this change was to avoid problems with decoding certain OpenSSH private keys.

If a "PEM-like" OpenSSH format private key:

1. has no comment;
2. is of a length such that there is no padding bytes at the end of the "Unencrypted list of N private keys"; ***and***
3. is of a length such that the base64-encoded form of the key does not require any `=` bytes for padding;

then `ssh_key::private::PrivateKey::from_openssh` failed to successfully parse the key.

The root cause was `base64ct` (prior to RustCrypto/formats#1387) incorrectly rejecting zero-length reads, *only* when the base64-encoded buffer was empty.
This only happened for reading empty comments, because comments are at the end of the key.
It *wouldn't* happen if:

1. the key had a comment, because that wouldn't be a zero-length read;
2. there were padding bytes in the "Unencrypted list of N private keys", because those padding bytes would still be in the buffer, so the buffer wasn't empty; *or*
3. there were base64 `=` padding characters, because those would cause the decoder to believe a read would succeed (even though it wouldn't if the read was longer than zero bytes).

Debugging this was... an amusement.

The most reliable way to demonstrate this was with an ECDSA P-256 key without a comment (easily generated with `ssh-keygen -t ecdsa -b 256 -C '' -N '' -f <file>`),
because they're *usually* (but not *always*) an appropriate length to trigger the bug.
Amusingly (cough), the existing ECDSA P-256 test key in `ssh-key/tests/examples/id_ecdsa_p256` is one of the outliers, as its `d` is 33 bytes, rather than 32, which means that key (when stripped of its comment) *doesn't* trigger the bug.

Adjust to the changes to `base64ct` that reject zero-length decode() calls as invalid.

The underlying trigger for this change was to avoid problems with decoding certain OpenSSH private keys.

If a "PEM-like" OpenSSH format private key:

1. has no comment;
2. is of a length such that there is no padding bytes at the end of the "Unencrypted list of N private keys"; ***and***
3. is of a length such that the base64-encoded form of the key does not require any `=` bytes for padding;

then `ssh_key::private::PrivateKey::from_openssh` failed to successfully parse the key.

The root cause was `base64ct` (prior to RustCrypto/formats#1387) incorrectly rejecting zero-length reads, *only* when the base64-encoded buffer was empty.
This only happened for reading empty comments, because comments are at the end of the key.
It *wouldn't* happen if:

1. the key had a comment, because that wouldn't be a zero-length read;
2. there were padding bytes in the "Unencrypted list of N private keys", because those padding bytes would still be in the buffer, so the buffer wasn't empty; *or*
3. there were base64 `=` padding characters, because those would cause the decoder to believe a read would succeed (even though it wouldn't if the read was longer than zero bytes).

Debugging this was... an amusement.

The most reliable way to demonstrate this was with an ECDSA P-256 key without a comment (easily generated with `ssh-keygen -t ecdsa -b 256 -C '' -N '' -f <file>`),
because they're *usually* (but not *always*) an appropriate length to trigger the bug.
Amusingly (cough), the existing ECDSA P-256 test key in `ssh-key/tests/examples/id_ecdsa_p256` is one of the outliers, as its `d` is 33 bytes, rather than 32, which means that key (when stripped of its comment) *doesn't* trigger the bug.